Preservation of priority traffic in communications systems

ABSTRACT

Systems and methods for restoring lost or corrupted data in packets that traverse a packet-switched network. In some embodiments, a device at the edge of a packet switched network may restore data that was originally inserted in a packet header by a sender, but overwritten or bleached during transport over a network by identifying an associated packet, and transferring a value from the associated packet to the packet.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication Ser. No. 63/161,850 filed Mar. 16, 2021.

BACKGROUND

The subject matter of this application generally relates to theprovision of Internet traffic through CATV or other communicationsnetworks.

In packet-switched networks such as the Internet, network reliabilitycan be degraded in several manners, including packet loss when thenetwork drops packets due to congestion, as well as latency whichrepresents the delay time it takes for a packet to traverse the networkand the various queues in which the packets are held. To manage thesevarious issues, data providers implement Quality of Service (QoS)protocols that either prioritize among traffic or guarantee a certainlevel of performance to a data flow.

One such protocol implements a Differentiated Services (DiffServ)architecture that uses a field in IP packet headers to mark individualpackets with a priority code, called a DSCP value. Based on the DSCPvalue, routers and switches use various scheduling strategies to tailorperformance to expectations. Stated simply, the DSCP value indicates apriority for the packet, and packets marked with higher priorities aregiven scheduling precedence in the network to more quickly and reliablydeliver the packet through the network.

While other QoS architectures are possible, these are often unwieldy asthey require that prioritized traffic be identified using e.g., the IPaddresses and ports involved in the priority communications. With DSCPclassification, prioritization is simplified as there is no need to bekeep track of IP Addresses or TCP/UDP Port values, as a single value canbe written into the basic configuration file for a device to map trafficmarked with a particular DSCP value to a specific service flow.

Preserving DSCP markings attached to packets as they traverse thenetwork is essential for effective implementation of a DiffServarchitecture. Unfortunately, the DSCP marking are frequently rewrittento a new priority, or sometimes zeroed out (referred to as “bleaching”)during transit due to the packet headers being processed by networkdevices that are DiffServ-unaware.

What is desired, therefore, are systems and methods that better preservepriority information attached to packets that traverse a network.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, and to show how the samemay be carried into effect, reference will now be made by way of exampleto the accompanying drawings, in which:

FIG. 1 shows an exemplary header for a TCP-IP packet using the IPv4protocol, having a Type of Service (ToS) field.

FIG. 2 shows an exemplary communications network where theclassification information in the ToS field of FIG. 1 is prone to beingoverwritten.

FIG. 3 shows exemplary fields of IPv4 and DS-Lite compliant IPv6packets, respectively.

FIG. 4 shows an exemplary process of mirroring some of the fields in thepackets shown in FIG. 3.

FIG. 5 shows a system that uses the process of FIG. 4 to recover lost ormodified values of the ToS field.

FIG. 6 shows an alternate embodiment of the system of FIG. 5 thatincludes a Flow Label value.

FIG. 7 shows an exemplary method of hashing the fields of FIG. 3 toproduce a unique identifier for a flow in an efficient manner.

FIGS. 8-10 shows an exemplary method to recover round-trip timing datausing the system of FIG. 5.

FIG. 11 shows pseudocode that implements the procedure of FIG. 7.

DETAILED DESCRIPTION

As previously noted, some Quality of Service (QoS) protocols forcommunications networks implement a Differentiated Service (DiffServ)solution that stores a value in the IP header of a data packet toindicate the priority a network should allocate to the packet relativeto other packets. FIG. 1, for example, shows an exemplary TCP/IPv4packet 10 that includes an IP header 18 and a TCP header 20. The IPheader 18 includes a Type of Service (ToS) field 20. The ToS field 20 isan 8-bit identifier that was originally intended to store a six-bitvalue where the first three bits specified a precedence or importancevalue, the next three bits each specified a normal or improved handlingfor delay, throughput, and reliability, respectively, and the last twobits were reserved. In practice, however, the first three bits assignedfor precedence were never used. Later, the DiffServ architecturespecified the use of the ToS field to store a 6-bit code that indicatesthe precedence for a packet. The remaining two bits of the 8-bits areused to signal congestion control, defined by RFC3168. These bits may bemodified by middle-boxes (or intermediary routers) and are used tosignal congestion that may occur across the end-to-end path. Thefollowing table shows common code values and their meanings.

TABLE 1

Description WebRTC [4] DSCP value (RFC 4594 [21]) Flow Type/PriorityCS1 ® Low-priority data Any/Very Low AF42 ® Multimedia conferencing1/Medium or High EF ® Telephony 1/Medium or High CS0 Standard Any/LowAF11, AF12, AF13 High-throughput data 4/Medium (AF11 only) AF21Low-latency data 4/High AF31 Multimedia streaming 3/High AF41 Multimediaconferencing 2/High CS4 Real-time interactive not defined CS5 Signalingnot defined CS7 Reserved for future use not defined 1, 2, 4, 6, 41Undefined values not defined

indicates data missing or illegible when filed

Under the DiffServ architecture, packets are marked either by thetraffic sources themselves or by edge devices where the traffic entersthe network. In response to these markings, routers and switches usevarious queuing strategies to tailor performance to requirements.Routers and switches supporting DiffServ configure their networkscheduler to use multiple queues for packets awaiting transmission frombandwidth-constrained interfaces. Router vendors provide differentcapabilities for configuring this behavior, to include the number ofqueues supported, the relative priorities of queues, and bandwidthreserved for each queue. For example, some services require low jitterand low latency—e.g., Voice-over-IP (VoIP) and these packets areprioritized using the DSCP field. When such a packet must be forwardedfrom an interface with queuing, it is given priority over lower prioritypackets, for example those tagged as merely “best effort” in the DSCPfield.

As also noted previously, however, often the 6-bit DSCP values areoverwritten with other values, or simply zeroed out (bleached). Thisphenomenon occurs due to the differing treatment accorded to the ToSfield by various network components. For example, some equipment mightstill be configured to use outdated semantics for the ToS field.Alternatively, incorrect router configurations may alter values in a ToSfield. One estimate indicated that up to one-fourth of IPv4 routersre-marked DSCP values, with a significant number of those exhibitingbleaching, and others even inverting the priority specified in the DSCPfield. Such behavior may obviously lead to severe disruption of prioritytraffic.

Referring to FIG. 2, for example, a communications network may comprisean operator network 52 that routes traffic between a home 54 and theInternet 56. The exemplary network of FIG. 2 may utilize IPv4 traffic,or alternately any other suitable protocol that implements DSCP fieldsin packet headers such as IPv6 etc. The operator network 52 is shown forexemplary purposes as a Hybrid Fiber Coax (HFC) network of a Cable TV(CATV) provider where data is transmitted over the operator networkbetween a cable modem and/or gateway 58 at a subscribers premises and aCMTS 60, typically at a head end of the operator, but those of ordinaryskill in the art will appreciate that other topologies may also benefitfrom the disclosure provided herein, such as Distributed AccessArchitectures where, e.g. a Remote MACPHY or other edge device relaystraffic to and from the Internet or other packet-switched network aswell as other architectures including all-optical networks such as Fiberto the Premises (FTTP), wireless networks, etc.

Assume that in the communications network of FIG. 2, the resident of thehome 54 is exchanging priority traffic with another user via theInternet. The priority traffic may be VoIP traffic, gaming traffic forwhich low latency is desired, or other such traffic where theapplications providing these services mark the ToS fields of theirrespective communications with values for the data being exchanged.Thus, in this architecture, an IPv4 packet 62 may be assembled andassigned a DSCP priority value “EF” that is inserted into the ToS field12 of packet header 66. The packet 62 is then communicated to theoperator network 52 through gateway 58, and from the operator network 52to the Internet 56 via CMTS 60. Throughout this portion of the process,the network 52 is most always able to retain the DSCP value insertedinto the header of the packet 62. But once the packet 62 is releasedinto the Internet, the DSCP value may be modified or bleached beforereceipt by the operator network 52 or other network servicing theintended recipient of the packet 62, and this can unduly delay deliveryof the packet 62 to the intended recipient.

This can be seen in the reverse flow from the Internet 56 back to thehome 54. Applications that require prioritization typically involvetwo-way communications, e.g. VoIP, gaming applications, videoconferencing, etc. Thus, the packet 62 sent to a recipient will generatean associated return packet 63 that also would have been assembled witha DSCP field value, typically identical to that of packet 62, i.e. “EF”in this instance. Again, however, because the packet-switched Internetnetwork is prone to overwriting or bleaching that value, the properclassification fails; the CMTS 60 receives the incorrect DSCP value of“00” and therefore does not prioritize the packet during transport inthe operator network 52, potentially leading to delays.

The present specification discloses novel systems and methods for anoperator network that receives packets communicated via the Internet orother packet-switched network to recover values originally inserted intoDSCP fields, even when those values were modified or bleached whiletraversing the packet switched network. Specifically, as noted earlier,applications that require prioritization typically involve two-waycommunications, in which an initial packet sent from a first device to asecond device will quickly generate a responding packet from the seconddevice to the first device. Each of these devices have respectivelyunique IP/port address combinations that are recorded in both theinitial packet and the responding packet. FIG. 3, for example shows apacket 62 that may be assembled with fields 68 either specified by theIPv4 and IPv6 protocols, or with fields 69 of the DS-Lite IPv6 protocol.If assembled according to the IPv4/IPv6 protocols, the header of thepacket 62 will include a source IP address (SIP) field 70, a destinationIP (DIP) address field 72, a source port (SPORT) field 74, and adestination port (DPORT) field 76. If assembled in accordance withDS-Lite IPv6, the header of the packet will include source anddestination IP addresses for both IPv4 and IPv6 protocols as well as thesource and destination port addresses, i.e. 4SIP, 4DIP, 6SIP, 6DIP,SPORT, and DPORT. Each packet also includes other fields/values such asthe Protocol (PROT) value 73 along with values in other fields.

Referring to FIG. 4, when an initial packet 62 is transmitted in anupstream direction from source device 58 (e.g., a cable modem and/orgateway) to a destination, and a response packet 63 is received from thedestination to the source 58, a relationship between the fieldsdescribed in the preceding paragraph can be easily seen. Specifically,the SIP/DIP combination(s) of the packets 62 and 63 will be mirrored, aswill the SPORT/DPORT combination. In other words, the values ABCDEFG infield tuple 82 of packet 62 as shown in the figure are simply rearrangedin the order BADCEGF of the tuple 83 of packet 63. Also, as notedearlier, the response will typically be returned in a short amount oftime. This means, that upon receipt of the packet 62, the CMTS 60 orother edge device in the operator network 52 can predict receipt of aresponse packet with known values for the source and destination IPaddresses and source and destination ports.

Referring to FIG. 5, an improved system 100 may include a CMTS 102 orother device at the edge of the network 56 capable of recovering lostDSCP values. A source device at home 54 may be in communication with adestination device at a location (not shown) via the Internet 56, andthe communications between these devices may require assignment of aspecified level of priority. Accordingly, upstream packet 62 may beassembled—in this example according to the IPv4 protocol—and a DSCPvalue of “EF” inserted into the ToS field 12, which as noted in Table 1specifies telephony service with a priority of medium or high. Thepacket 62 with this DSCP value is forwarded to the gateway 58 and on tothe CMTS 102.

The CMTS 102 parses the packet header to retrieve the tuple 82 shown inFIG. 4, which since it is an IPv4 header, has values represented asCDEFG in this figure for the 5-tuple source/destination IP addresses,PORT, and source/destination port addresses, respectively. Those ofordinary skill in the art would appreciate that if IPv6 were to be usedinstead of IPv4, the tuple 82 would have seven values in the tuple,specified by ABDCEFG. After retrieving the tuple CDEFG, the CMTS 102mirrors the tuple as described with respect to FIG. 4, i.e. it producesa mirrored tuple DCEGF, which represents the expected source/destinationIP addresses and port addresses of a packet 63 sent in the downstreamdirection in response to the packet 62. The CMTS may preferably performa hash of the mirrored tuple DCEFG and store the hash value along withthe DSCP value “EF.”

As with the example described with respect to FIG. 2, the packet 62 maybe sent to the destination, which will in turn respond with a downstreampacket 63, and that downstream packet 63 should also have an appendedDSCP value of “EF” in the header. However, the DSCP value may beoverwritten or bleached during transport via packet-switched network 56,as is shown in FIG. 5 as an incorrect DSCP value of “00.” Unlike thesystem of FIG. 2, however, upon receipt of packet 63 the CMTS 102 parsesthe packet header, retrieves the tuple DCEFG shown in FIG. 4, andperforms a hash operation on it. The CMTS 102 compares that hash to thestored, mirrored hash of packet 62 and recognizes it as a response tothe packet 62. The CMTS 102 then replaces the DSCP value of “00” in theheader of packet 63 with the stored value of “EF” and forwards it onthrough the operator network 52, which will then recognize the properpriority assigned to the packet.

Those of ordinary skill in the art will appreciate that the foregoingprocess may be easily modified by having the CMTS 112 hash the fieldsCDEFG of the upstream packet 62 without mirroring but process thedownstream packet 63 by first mirroring the source and destinationIP/port address fields as previously disclosed, then hashing thosefields. In either circumstance the CMTS 102 will be able to match theupstream packet 62 with the response packet 63.

In some embodiments, the CMTS 102 may append a time counter or thresholdto the stored DSCP values and their associated hashes. As already noted,in typical priority upstream packets receive responsive downstreampackets within a short period of time, which may be on the order ofmilliseconds. Thus, in some embodiments, the DSCP values and theirassociated hashes may expire if a response is not received within aspecified time. Such embodiments may ensure that the wrong DSCP valuesare not replaced into a ToS field 12.

Preferably, the foregoing processing is only performed once per IP flowper direction (upstream/downstream). A flow is a sequence of packetsthat are sent from a particular source to a particular, unicast ormulticast, destination. Thus, the initial packet 62 and the responsepacket 63 would typically be the first packets in ongoing respectivelypaired IP flows, with every packet of each flow subject to the samepriority. Therefore, in a preferred embodiment, in addition to recordinga DSCP value and an associated mirrored hash for the initial packet 62,the CMTS may also generate a first flow ID to identify all ongoingupstream packets exchanged in the prioritized IP flow between the sourcedevice at the home and the CMTS, and would similarly generate a secondflow ID to identify all ongoing downstream packets exchanged in theprioritized flow between the CMTS and the destination device. After theinitial processing (slow path processing) generates the mirrored hashvalue and the associated DSCP value, each are associated with theidentified upstream flow ID so that subsequent upstream packetsidentified with the same flow ID can simply be processed withoutadditional hashing, recording of DSCP values, etc. (fast pathprocessing). Similarly, once the downstream flow ID is generated, thatflow ID may be used to associate packets in that flow with the properDSCP value. In some situations, the CMTS 102 may receive response packet63 before it has finished the slow path processing, and before it hasrecorded a DSCP value for possible replacement into the packet 63.However, once the slow path processing is completed by CMTS 102, allother packets exchanged in the IP flow will have the proper DSCP packetinserted.

Those of ordinary skill in the art will also appreciate that upstreampackets 62 may also have had their DSCP headers bleached or otherwisemodified upon delivery to the recipient through the packet-switchednetwork 56. However, where the recipient is also connected to thenetwork 56 via the operator network 52, or another operator network thatuses the systems and methods described herein, these DSCP values may berestored because, upon receipt of the first packet 62, the responsepacket 63 will include a proper DSCP value in the ToS field 12, and thatvalue will be recorded at the edge of the operator network so thatsubsequent packets from the home 54 may have the proper DSCP valuereinserted where necessary.

FIG. 6 shows an alternate system 110 by which a CMTS 112 makes use of a20-bit Flow Label field 114 implemented in the IPv6 protocol.Specifically, a cable modem or other device may insert a specific valueinto an assigned bit of the Flow Label field 114 of outgoing IPv6packets. In this embodiment, this bit would signal whether such trafficmust have its DSCP value recorded by the CMTS 112, along with the hashedand mirrored tuple information as described above. In this manner, theCMTS 112 or other device can quickly segregate important traffic thatrequires special handling (slow path processing) and the remainder ofthe traffic that does not.

Moreover, in an additional or alternate embodiment, the remaining bitsof the Flow Label field 114 may be used by CMTS 112, gateway 58, orother device to provide more granular handling or control of packets.This approach permits the use of simplified classifiers based on theIPv6 Flow Label value, that can be used to apply to both upstream anddownstream traffic.

The CM/GW can set a Flow Label value in outbound packets so they may bepassed for classification/QoS based on the flow label. Once the upstreamDSCP values are recorded based on the flow label, the IPv6 packet isforwarded to the CMTS where the previously described scheme involvingdynamically created mirror classification is applied for those packetscarrying a Flow Label, where the CMTS associates the packet with amirrored hash, the flow label, and the DSCP value. The returningdownstream traffic is unlikely to have an IPv6 Flow Label value filledout, so the CMTS performs traffic identification based on the mirroredhash value as described earlier. Any matching traffic has its associatedupstream information retrieved, including the original IPv6 Flow Label.The CMTS applies this value to the packet before sending on for DOCSISclassification/QOS handling. The overwritten IPv6 Flow Label in themodified packet is matched by the downstream classifier, ensuring thatit is properly classified to the appropriate service flow for QoS.

In some embodiments, because the flow label value 114 provides greatergranularity of treatment of packet priority than does a DSCP value, thepresence of a flow label value 114, with its classifier and associatedcode, may supplant any treatment specified by a DSCP value in the ToSfield 12. Thus, in some implementations the CMTS 112 may have a policyto either retain or overwrite a DSCP value received in a downstreampacket. Moreover, in some embodiments, the CMTS may use different flowlabels between the home 54 and the CMTS 112 than between the CMTS 112and the CMTS 112 and the Internet.

The modification of the DSCP and Flow Label values may preferably beperformed as part of the slow-path processing of the initial packets ofa flow, before performing the required configuration to enable theeventual rewrite to be performed by fast-path processing.

Regardless of whether an implementation uses the flow label field of theIPv6 protocol, as noted earlier the CMTS 102 of FIG. 5 and/or the CMTS112 of FIG. 6 preferably identifies a flow to which the DSCP values,Flow Label values, and mirrored hash values are appended in the slowpath processing for later application in the fast path processing.Preferably, the flow ID is chosen randomly, in a “pseudo” manner, whichmakes any set of bits within the flow label field suitable for use as ahash key to look up data associated with the flow. Referring to FIG. 7,for example, a first process 120 may receive an initial packet 62 fromwhich a flow ID is to be constructed. The packet 62 may comprise anumber of header fields, such as the ten fields shown in the DS-LiteIPv6 header of FIG. 3. In this manner, these fields (A-J) may beselected and hashed with a hash function to produce respective hashfunctions 124 that serve as the flow ID for both the upstream anddownstream directions, noting again that the source and destinationIP/port address fields of the upstream packet 62 will either have to bemirrored before hashing, or the corresponding fields of downstreampackets will need to be so mirrored before hashing so that the upstreamand downstream hash values may be matched to each other.

The foregoing procedure will produce an appropriate unique flow ID, butit should be noted that performing hash operations is computationallyexpensive, and therefore performing a hash of one set of fields of apacket to produce a flow ID in the upstream and downstream directions,and performing a hash of a different set of fields to produce the hashedtuples 82/83 shown in FIG. 4—done to match the initial source packet 62with a corresponding response packet, is not ideal. Accordingly, FIG. 7also shows an improved process 122, which takes advantage of the factthat the source and destination IP/port address fields of the upstreampacket 62 and downstream packet 63 were already hashed, and therefore donot have to be individually hashed twice. Instead, theirpreviously-computed hashed value may simply be hashed with the remainingfields of the tuples 82/83 shown in FIG. 4. Thus, the when the CMTS 102or 112 receives the initial upstream packet it only selects theremaining fields that are to be used for the upstream flow ID—e.g.,fields H, I, and J of the exemplary DS-Lite IPv6 header. In the upstreamdirection, the hash function 132 is applied to the combination of thosefields with the previously-hashed (possibly mirrored) tuple 82 toproduce the unique flow ID. The same process occurs in the downstreamdirection for packet 63; the downstream flow ID is reconstructed byapplying the hash function 132 to the combination of fields H, I, J withthe same hash of tuples 83 that was used to match DSCP fields. Byreusing the first hashed value, the second has operation is lesscomputationally expensive. FIG. 11 shows exemplary pseudocode forimplementing the foregoing procedure.

FIGS. 8-10 show an exemplary feature of the disclosed systems andmethods where a CMTS 102 may calculate round trip times for packets totraverse the operator network 52 as well as the packet-switched network56. FIG. 9 shows exemplary round-trip times recorded for operatornetworks versus the Internet, for example. These round-trip times may beof use in a number of applications. For instance, such data may be sentto an analysis module to determine the benefits achieved by low latencyservices sold, etc. Referring to FIG. 8, for example, in this embodimentthe packet 62 may preferably be sent along with a sync message 140 towhich the CMTS appends a first timestamp (uP1 TS1) indicating the timethat the upstream packet 62 was received by the CMTS. The CMTS 102/112then forwards the packet 62 to the Internet/packet switched network 56.Once received, the packet 63 may be sent to the CMTS along with anacknowledgement message 142, to which the CMTS may append a secondtimestamp (dP1 TS2) indicating the time the CMTS receives packet 63.Once the packet 63 is received by the cable modem/gateway 52, anotheracknowledgment 144 is sent to the CMTS which appends a third timestamp(uP2 TS3) to the acknowledgment 144. From these timestamps the values around-trip time for operator network 52 may be calculated and around-trip time for the packet-switched network 56 also calculated.

Referring to FIG. 10 for example, the CMTS 102, 112 may include anupstream line card 146 and a downstream line card 148. In process A, theupstream line card 146 may receive the sync message 140, calculate thebidirectional hash Z (the Flow ID), append its timestamp uP1 TS1 to thesync message, and in process B send flow ID to the downstream line card148. The upstream line card also sends the packet 62 to its destinationvis the Internet, and in process C, the downstream line card 148 recordsthe flow ID by which it can identify the associated acknowledgement.Upon receipt of packet 62, the destination device (not shown) returnsthe acknowledgment 142 to which the downstream line card 148 appendstimestamp dP1 TS2 in process D, and in process E forwards the timestampdP1 TS2 to the upstream line card 146 along with the flow ID. Thedownstream line card 148 also forwards the packet 63 to the gateway 58.The upstream line card 146 can now calculate the Internet RTT in processF as the difference between the time stamps dP1 TS2 and uP1 TS1.

FIG. 10 also shows that the foregoing calculations do not change if theflow ID determination is delayed by the slow path processing because thetimestamps associated with the packets 62 and 63 are still calculated asthey are received. For example, assuming that the determination of flowID “Z” is sufficiently delayed that the packet 63 had previously beenreceived by the downstream line card 48 and forwarded to the gateway 58,the downstream line card can in process H simply send thepreviously-recorded time stamp dP1 TS2 at a later time, at which pointin process I the line card 146 may simultaneously calculate both theInternet RTT as well as the operator network RTT. IN process J, theseresults may be pushed to an outside analysis module or other device thatmakes use of such information.

Those of ordinary skill in the art will appreciate that Note that it ispossible that the forgoing functionality could be performed by aseparate external device connected to the CMTS (if the CMTS did notsupport this functionality).

It will be appreciated that the invention is not restricted to theparticular embodiment that has been described, and that variations maybe made therein without departing from the scope of the invention asdefined in the appended claims, as interpreted in accordance withprinciples of prevailing law, including the doctrine of equivalents orany other principle that enlarges the enforceable scope of a claimbeyond its literal scope. Unless the context indicates otherwise, areference in a claim to the number of instances of an element, be it areference to one instance or more than one instance, requires at leastthe stated number of instances of the element but is not intended toexclude from the scope of the claim a structure or method having moreinstances of that element than stated. The word “comprise” or aderivative thereof, when used in a claim, is used in a nonexclusivesense that is not intended to exclude the presence of other elements orsteps in a claimed structure or method.

1. A device in a communications network that receives a packet from asender, the device configured to selectively use the packet to identifya different packet from a different sender and write data from the firstpacket to the different packet.
 2. The device of claim 1 where thedevice is located in an operator network between a subscriber and apacket-switched network.
 3. The device of claim 1 where the deviceidentifies the different packet based on rearranging data in a selectiveone of the first packet and the different packet.
 4. The device of claim3 where the different packet is identified using a hash of therearranged data.
 5. The device of claim 1 where the data written fromthe first packet to the different packet causes the different packet tobe processed differently by the communications network.
 6. The device ofclaim 1 where the data is located in a field of an IP header in thepacket.
 7. The device of claim 1 where the device is configured to usedata from the packet to identify sequential ones of a plurality ofsubsequent packets received from the different sender, at a timesubsequent to the identification of different packet, where the deviceis configured to use less time identifying the sequential ones of theplurality of subsequent packets than used to identify the differentpacket.
 8. A device that receives a packet from a sender through apacket-switched network, the device configured to selectively restore adata value in the packet changed in transit through the packet-switchednetwork, where the device determines the restored value from a pluralityof potential values prior to the packet being received from the sender.9. The device of claim 8 configured to determine the restored value froma plurality of potential values prior to the packet being sent from thesender.
 10. The device of claim 8 configured to determine the restoredvalue from a plurality of potential values prior to the packet beingconstructed by the sender.
 11. The device of claim 1 in an operatornetwork between a subscriber and the packet switched network.
 12. Thedevice of claim 11 where the restored value causes the packet to beprocessed differently by the operator network.
 13. The device of claim11 where the packet is the first packet identified from the sender bythe device in an ongoing IP flow.
 14. A method comprising: receiving afirst packet from a sender, the first packet having a header a pluralityof fields; rearranging the plurality of fields and using the rearrangedplurality of fields to associate the first packet with a second packet;writing a value received from one of the plurality of fields in aselective one of the first packet and the second packet to acorresponding field in the other selective one of the first packet andthe second packet; and sending the other selective one of the firstpacket and the second packet to a destination over a network.
 15. Themethod of claim 14 where transferring the value to the other selectiveone of the first packet and the second packet changes its processingthrough the network.
 16. The method of claim 14 where the step ofrearranging the plurality of fields mirrors values in selective pairs offields.
 17. The method of claim 14 where the transferred value is atleast one of a DSCP value and a Flow ID.
 18. The method of claim 14including the step of hashing the rearranged plurality of fields toproduce a hashed value that identifies the selective one of the firstpacket and the second packet.
 19. The method of claim 18 including thestep of hashing a second plurality of fields in the header to produce asecond hashed value that identifies a flow associated with the firstpacket, the second hashed value different than the first hashed value.20. The method of claim 18 where the second hashed value is used toidentify a subsequent packet from the sender, the identification used toprocess the subsequent packet faster than the first packet.